The present invention relates to the field of data processing and more specifically to event notification data processing which distributes event messages from suppliers (called, hereinafter, xe2x80x9cpublishersxe2x80x9d) of data messages to consumers (called, hereinafter xe2x80x9csubscribersxe2x80x9d) of such messages. While there are many different types of known event notification systems, the subsequent discussion will describe the publish/subscribe event notification system as it is one of the most common.
Publish/subscribe data processing systems (and event notification systems in general) have become very popular in recent years as a way of distributing data messages (events) from publishing computers to subscribing computers. The increasing popularity of the Internet, which has connected a wide variety of computers all over the world, has helped to make such publish/subscribe systems even more popular. Using the Internet, a World Wide Web browser application (the term xe2x80x9capplicationxe2x80x9d or xe2x80x9cprocessxe2x80x9d refers to a software program, or portion thereof, running on a computer) can be used in conjunction with the publisher or subscriber in order to graphically display messages. Such systems are especially useful where data supplied by a publisher is constantly changing and a large number of subscribers needs to be quickly updated with the latest data. Perhaps the best example of where this is useful is in the distribution of. stock market data.
In such systems, publisher applications of data messages do not need to know the identity or location of the subscriber applications which will receive the messages. The publishers need only connect to a publish/subscribe distribution agent process, which is included in a group of such processes making up a broker network, and send messages to the distribution agent process, specifying the subject of the message to the distribution agent process. The distribution agent process then distributes the published messages to subscriber applications which have previously indicated to the broker network that they would like to receive data messages on particular subjects. Thus, the subscribers also do not need to know the identity or location of the publishers. The subscribers need only connect to a distribution agent process.
One such publish/subscribe system which is currently in use, and which has been developed by the Transarc Corp. (a wholly owned subsidiary of the assignee of the present patent application, IBM Corp.) is shown in FIG. 1. Publishers 11 and 12 connect to the publish/subscribe broker network 2 and send published messages to broker network 2 which distributes the messages to subscribers 31, 32, 33, 34. Publishers 11 and 12, which are data processing applications which output data messages, connect to broker network 2 using. the well known inter-application data connection protocol known as remote procedure call (or RPC) (other well known protocols, such as asynchronous message queuing protocols, can also be used). Each publisher application could be running on a separate machine, alternatively, a single machine could be running a plurality of publisher applications. The broker network 2 is made up of a plurality of distribution agents (21 through 27) which are connected in a hierarchical fashion which will be described below as a xe2x80x9ctree structurexe2x80x9d. These distribution agents, each of which could be running on a separate machine, are data processing applications which distribute data messages through the broker network 2 from publishers to subscribers. Subscriber applications 31, 32, 33 and 34 connect to the broker network 2 via RPC in order to receive published messages.
Publishers 11 and 12 first connect via RPC directly to a root distribution agent 21 which in turn connects via RPC to second level distribution agents 22 and 23 which in turn connect via RPC to third level distribution agents 24, 25, 26 and 27 (also known as xe2x80x9cleaf distribution agentsxe2x80x9d since they are the final distribution agents in the tree structure). Each distribution agent could be running on its own machine, or alternatively, groups of distribution agents could be running on the same machine. The leaf distribution agents connect via RPC to subscriber applications 31 through 34, each of which could be running on its own machine.
In order to allow the broker network 2 to determine which published messages should be sent to which subscribers, publishers provide the root distribution agent 21 with the name of a distribution stream for each published message. A distribution stream (called hereinafter a xe2x80x9cstreamxe2x80x9d) is an ordered sequence of messages having a name (e.g., xe2x80x9cstockxe2x80x9d for a stream of stock market quotes) to distinguish the stream from other streams (this is known as xe2x80x9ctopic basedxe2x80x9d publish/subscribe, another well known model is called xe2x80x9ccontent based publish/subscribe which involves matching publishers and subscribers by the content of the messages rather than by the topic). Likewise, subscribers provide the leaf distribution agents 31 through 34 with the name of the streams to which they would like to subscribe. In this way, the broker network 2 keeps track of which subscribers are interested in which streams so that when publishers publish messages to such streams, the messages can be distributed to the corresponding subscribers. Subscribers are also allowed to provide filter expressions to the broker network in order to limit the messages which will be received on a particular stream (e.g., a subscriber 31 interested in only IBM stock quotes could subscribe to the stream xe2x80x9cstockxe2x80x9d by making an RPC call to leaf distribution agent 24 and include a filter expression stating that only messages on the xe2x80x9cstockxe2x80x9d stream relating to IBM stock should be sent to subscriber 31).
The above-described publish/subscribe architecture provides the advantage of central co-ordination of all published messages, since all publishers must connect to the same distribution agent (the root) in order to publish a message to the broker network. For example, total ordering of published messages throughout the broker network is greatly facilitated, since the root can easily assign sequence numbers to each published message on a stream. However, this architecture also has the disadvantage of publisher inflexibility, since each publisher is constrained to publishing from the single root distribution agent, even when it would be much easier for a publisher to connect to a closer distribution agent.
In the FIG. 1, a publisher application 11, running on one computer, is, for example, a supplier of live stock market data quotes. That is, publisher application 11 provides frequent messages stating the present value of share prices. In this example, publisher application 11 is publishing messages on a stream called xe2x80x9cstockxe2x80x9d which has already been configured in the broker network 2. As is well known, when publisher 11 wishes to publish a stock quote message to stream xe2x80x9cstockxe2x80x9d, publisher 11 makes an RPC call to the root distribution agent 11 which is at the top level of the broker network tree structure. In this example, subscriber application 32, running on another computer, has sent a subscription request via an RPC call to leaf distribution agent 24, which is at the bottom level of the tree structure, indicating that subscriber 32 would like to subscribe to stream xe2x80x9cstockxe2x80x9d.
Thus, whenever publisher 11 publishes a data message to stream xe2x80x9cstockxe2x80x9d the distribution tree structure of broker network 2 channels the message down through the root distribution agent 21, through any intermediary distribution agents (e.g., 22 in the example of FIG. 1) and through the leaf distribution agent 24 to the subscriber 32. This involves a series of RPC calls being made between each successive circle in the diagram of FIG. 1 connecting publisher 11 and subscriber 32 (i.e., 11 to 21, 21 to 22, 22 to 24 and 24 to 32).
FIG. 2 shows a different publish/subscribe architecture where publisher applications can publish messages to the broker network by directly communicating with any one of a plurality of distribution agents (brokers). For example, publisher application 201 is shown communicating directly with Broker 12. There is no requirement in this architecture that all publisher applications communicate directly with a top (or root) distribution agent. Publisher application 201 can potentially communicate directly with any of the distribution agents shown in FIG. 2, in the described examples below it will be shown communicating directly with Broker 12.
Subscriber applications 202 and 203 would like to receive messages on the stream/topic that publisher application 201 is publishing on. Thus, subscriber applications 202 and 203 communicate directly with Brokers 1112 and 1221, respectively, to provide subscription data thereto informing the broker hierarchy of their desire to receive such published messages. Since the publisher application 201 is allowed to communicate directly with any of a plurality of distribution agents, the subscription data entered by the subscriber applications must be propagated throughout the broker network to each Broker shown in FIG. 2. This way, no matter which distribution agent the publisher application 201 happens to communicate directly with, the published messages will be able to be routed to the subscriber applications 202 and 203.
Publish/subscribe broker systems have commonly been integrated into multi-function message broker systems which are used to inter-connect applications which may be on heterogeneous platforms and may use different message formats. For example, Saga Software of Reston, Virginia (USA) (www.sagasoftware.com) have such a message broker product called xe2x80x9cSagavistaxe2x80x9d (a trademark of Saga Software). Further, Tibco Software Inc. of Palo Alto, Calif. (USA) (www.tibco.com) also have such a message broker called xe2x80x9cTIB/Message Brokerxe2x80x9d (both xe2x80x9cTIBxe2x80x9d and xe2x80x9cTIB/Message Brokerxe2x80x9d are trademarks of Tibco). In these multi-function message brokers, a set of pluggable data processing nodes is provided, with each node being dedicated to a specific data processing task, such as message format transformation, publish/subscribe message distribution, and a rules engine for deciding (based on a plurality of predefined rules) where an incoming message should be routed.
In these multi-function message broker products, when a subscriber application registers a subscription request with the broker, the subscriber application sends the subscription request to a publish/subscribe broker node specifying the topic of the desired subscription. The publish/subscribe broker node (usually in cooperation with a plurality of other such publish/subscribe broker nodes) then ensures that any published messages on that topic are sent to the subscriber application. Different subscribers may wish to receive the same published messages but in different message formats. For example, a subscriber in the United States may want to know IBM""s stock price per share in US dollars while another subscriber in the United Kingdom may want to know IBM""s stock price in UK (British) pounds.
In order to accommodate such format desires of various subscribers, the message broker would have to modify the topic after having performed a format transformation so that a subscriber can subscribe to this modified topic (rather than the original topic that the publisher published on) in order to receive the format-transformed messages. Alternatively, the publishers would have to publish the same messages in different formats(with each format having its own topic), thus doing away with the need for the broker to do the format transformation. Because the topic needs to correspond to the format in both of these cases, this can cause many problems. For example, it is very useful to carry out access control on a topic basis. That is, when deciding which subscribers can have access to which published messages, it is very useful to be able to use the topics of the messages to make such access control decisions. However, when the topics must be different for essentially the same group of messages because of format changes, such access control decisions become much more complex.
It would be clearly desirable to be able to use the same topic for a variety of different message formats in a message broker, but the present state of the art does not allow for this.
According to one aspect, the present invention provides a message broker data processing apparatus having: a unit for receiving published messages on a topic from a publisher application; a unit for processing the received messages; and a unit for distributing the processed messages to subscriber applications; wherein the unit for distributing includes a plurality of subscription point data processing nodes, a first subscription point data processing node distributes messages to a subscriber application which has previously registered a subscription request identifying the first subscription point data processing node with the broker apparatus.
Preferably, the unit for processing includes at least one message flow data processing node which performs a specific data processing operation; and wherein the apparatus further has: a unit for performing a detection that no subscriber application has registered a subscription request identifying a particular subscription point data processing node with the broker apparatus; and a unit for, in response to the detection that no subscriber application has registered a subscription request identifying a particular subscription point data processing apparatus, disabling the execution of a message flow data processing node which is uniquely associated with the particular subscription point data processing node.
According to a second aspect, the present invention provides a data processing method of carrying out the functionality discussed above with respect to the first aspect.
According to a third aspect, the present invention provides a computer readable storage medium having a computer program stored on it which, when executed on a computer system, carries out the functionality of the data processing method of the second aspect of the invention.
Thus, the present invention provides a message broker having a publish/subscribe capability where subscribers can receive messages in their desired formats without the need for either the broker or the publishers to modify the topic names used by the publisher, broker and subscriber. Instead, the publisher, broker and subscriber can use the same topic name even though the messages sent under this topic will be of differing formats. The presence of multiple subscription points within the broker provides for this ability.
As one advantage of the invention, access control can thus be easily carried out using the topic name. Further, the publisher application does not need to publish the same messages on a plurality of topics in order to accommodate subscribers who want publications in differing formats, thus decoupling the publisher application from having to deal with the varying desires of subscribers. The publisher need only publish messages in the format most convenient to that publisher.
Further, according to a preferred aspect of the present invention, a detection is performed that there are no subscriber applications which have registered a subscription naming a particular subscription point. In response to this detection, a message flow data processing node that is uniquely associated with that particular subscription point is prevented from being executed. This greatly saves on the amount of processing that is carried out. There is no need for such message flow data processing node(s) to execute because such message flow data processing nodes(s) is/are only processing messages which will be sent to a particular subscription point and since no subscriber application has registered a subscription request naming that subscription point, then there is no need for such message flow data processing node(s) to execute.